1. Field of the Invention
The invention relates to an electronic mail program. More particularly, the invention relates to an electronic mail program having a mailbox browser display which displays different icons for different types of mail item MIME types.
2. State of the Art
In recent years electronic mail (xe2x80x9cemailxe2x80x9d) has become widely used in business, education, and in personal communications. One of the features of electronic mail which is most convenient, particularly in business and in education, is the ability to attach a binary computer file to an email message. This feature enables email correspondents to rapidly share word processing documents, database documents, spreadsheet documents, multimedia documents, or virtually any kind of binary file created by a computer. There are, however, some serious limitations and inconveniences associated with attaching a binary file to an email message.
The original Internet mail system as defined in 1982 with RFC (Request for Comments) 821 and 822 had a number of important limitations. In particular, the system was not designed to carry large quantities of arbitrary data in an email message. In fact, the 1982 SMTP (Simple Mail Transport Protocol) standard required that an email message consist of a single message containing only ASCII characters in lines of 1000 characters (blocks of 32 k) or less.
The ability to send binary data through the Internet electronic mail system was made possible with the MIME (Multipurpose Internet Mail Extensions) standard for Internet messages. The original MIME standard was published as an Internet Request For Comments document (RFC 1341) and approved in June of 1992. (See Internet RFCs 2045,2046, and 2047 for the latest MIME standards documents.) The MIME standard describes how an email message should be formatted in order to be considered MIME compliant. MIME defines a set of message header fields and a set of message encoding standards that are designed to overcome the limitations of RFC 822 message formats and still be transportable through any of the numerous legacy mail transport systems in use on the Internet. (See specifically, N. Freed and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part 1: Format of Message Bodies, Network Working Group, Request For Comments (RFC 2045) November 1996.) MIME message header fields extend those defined in RFC 822 and describe the content and encoding type of the email message. Encoding schemes allowed in the MIME standard include xe2x80x9cquoted-printablexe2x80x9d, and xe2x80x9cbase64xe2x80x9d. In addition, three unencoded data types are allowed. These are labeled xe2x80x9c8 bitxe2x80x9d, xe2x80x9c7 bitxe2x80x9d, or xe2x80x9cbinaryxe2x80x9d. It should be noted that legacy gateways still do not handle binary data and nearly all MIME compliant messages encode binary data as xe2x80x9c7 bitxe2x80x9d, the default encoding for MIME.
Today MIME is implemented in all of the major electronic mail clients or xe2x80x9cUser Agentsxe2x80x9d, e.g. Microsoft Outlook and Outlook Express, Netscape Communicator, and Qualcomm Eudora. However, only a few MIME types including xe2x80x9ctext/plainxe2x80x9d, xe2x80x9ctext/htmlxe2x80x9d, xe2x80x9cmultipart/alternativexe2x80x9d, and xe2x80x9cmultipart/mixedxe2x80x9d can be handled by these programs. Probably the most important feature of the MIME standard that was that it allowed any binary data to be appropriately encoded and sent through the older SMTP system of mail gateways and exchanges. Mail client programs such as those listed above were modified to allow users to attach any type of file to a mail message. This was done by (a) including an appropriate encoding module to translate the binary data of an arbitrary file to an acceptable MIME encoding such as xe2x80x9c7 bitxe2x80x9d or xe2x80x9cbase64xe2x80x9d, (b) expanding the Mail client""s ability to handle messages with a MIME type set to xe2x80x9cmultipartxe2x80x9d, and (c) including the file specified by a user as a part of the xe2x80x9cmultipartxe2x80x9d message. For many years, mail client programs offered users only the two choices; they could send a simple text message (sent with xe2x80x9ccontent-type=text/plainxe2x80x9d) or they could attach any file to a simple text message (sent with xe2x80x9ccontent-type=multipart/mixedxe2x80x9d).
More recently the programs listed above have been extended to allow authors to use basic types of text formatting such as alternative fonts and styles by including these features in the mail client text editor and sending the message with a MIME type set to xe2x80x9ctext/htmlxe2x80x9d. Today Microsoft""s Outlook even allows a person to use Word, a full featured text editor, to author electronic mail messages by converting the Word file format to HTML before manually inserting it into the body of the mail message for sending. Nevertheless, mail client programs still rely exclusively on file attachments with message MIME types set to xe2x80x9cmultipartxe2x80x9d for any other type of file format.
If the sender and the receiver of the email message with the attached binary file are using the same brand and version of email program and both programs are configured in substantially the same way, the receiver""s email program should automatically apply the appropriate decoding to the attached binary file and produce a file which is identical to the file which was attached to the email by the sender. However, if the sender and receiver are using different email programs, the recipient may receive a file which must be decoded by the recipient using a separate decoding program.
Even after the file is properly received and decoded, it is often difficult for the receiver of the file to open the file. The receiver of the file might expect that xe2x80x9cclickingxe2x80x9d on the file icon will open the file. However, clicking on the file icon will often not open the file. It may result in an error message like xe2x80x9capplication not foundxe2x80x9d or, worse, it may result in the file being opened by an inappropriate application thereby displaying xe2x80x9cgibberishxe2x80x9d. The receiver of the file must have a program capable of reading (opening) the file. For example, if one attaches a spreadsheet file to an email message, the receiver of the file must have a spreadsheet program in order to open the file. Technically, it is not necessary that the receiver of the file have the same brand program as that which created the file. However, opening a file with a program which did not create it, though possible, can be very inconvenient. The receiver of the file must know what kind of file is attached to the email message, must know what program on their computer is capable of reading that type of file, must launch the program, must open the file from within the program, and wait while the program translates the file.
The limitations of Internet electronic mail can become even more frustrating if the sender and recipient are not using the same operating system (OS). Some mail attachment encoding schemes (and file compression schemes) are OS-dependent and it is possible that an email recipient could receive a file which is impossible to decode (or decompress).
These limitations in electronic mail have discouraged many people, particularly non-sophisticated computer users, from attaching files to electronic mail messages. In fact, for some novice users, the task of launching one application to create a document, saving the document, launching a separate email application to create an email message, and then locating the saved document for attachment to an email message is daunting enough to discourage them. In addition, novice users often complain that after xe2x80x9cdownloadingxe2x80x9d a file attached to an email message they cannot find the file on their hard disk.
Most email client software allows the user to sort items in the inbox by sender, subject, or date in order to locate more easily a particular mail item. In addition, most email client software indicates whether a particular message includes an attached file. This is indicated by an icon such as a paper clip icon or a generic document icon or a floppy disk icon, for example. However, the same icon is used regardless of the nature of the attachment and there is no way of knowing the nature of the attachment until the message is opened. Prior art FIG. 1 shows an example of a typical email inbox where some of the mail items have attached files indicated by the paper clip icon to the left of the subject name. Though not specifically shown in FIG. 1, those skilled in the art will appreciate that generic icons, such as !, , xe2x86x92, , etc., may also be displayed alongside the message subject to indicate various xe2x80x9cpropertiesxe2x80x9d of the message, such as whether it is a high priority message, whether you have already replied to the message, etc. These generic icons are usually monochromatic font characters taken from a xe2x80x9cdingbatsxe2x80x9d font or the like.
In the most recent versions of the major email client programs, an icon that represents the file type of an attached file is displayed in the body of the mail message after the message is opened by the user. This is possible because computer operating systems such as Microsoft Windows or Macintosh OS maintain data that associates information with each file type known to the system. This information includes a graphical icon and the location of programs that may be used to xe2x80x9copenxe2x80x9d, xe2x80x9ceditxe2x80x9d, or to perform a handful of other actions on the file. For example, in Microsoft Windows the system registry includes entries for each file type that is known to the system and at least some of the information described above is associated with the file type. When a user opens an electronic mail message with xe2x80x9ccontent-type=multipart/mixedxe2x80x9d, a mail client program built for Microsoft Windows (e.g. Microsoft Outlook) determines that the second part of the message was an attached file, identifies a line of text within the message such as, Attachment Converted: xe2x80x9cc: attach aFile.docxe2x80x9d, looks in the system registry for the icon associated with the file type xe2x80x9c.docxe2x80x9d, and displays the graphical icon inside the body of the message.
In current systems, MIME type is not used to associate icons to files, rather the file type extension is used. This creates important limitations in the ability to associate different versions of software or documents created by different versions of the software with different icons. For example all documents created by MS Word, regardless of which-version of Word was used, have the same file type (file extension) and as a result are associated with the same icon. This is true even though many newer versions of the files cannot be read by older versions of the software.
My previously incorporated parent application discloses electronic mail software which includes a main email component and a number of installable components. The installable components include authoring/reading components for creating/reading different kinds of documents and mailbox components for listing different kinds of messages or for listing messages in different styles. The main email component provides an underlying graphical user interface for functions directly associated with the storage and transfer of electronic mail messages, and also handles all data bundling and unbundling required to transform a message created by an authoring component into a MIME compliant message. The authoring/reading components act like applications embedded within the email program and allow specific types of documents such as spreadsheets, graphics, databases, etc. to be created from within the email program and emailed directly. The authoring/reading components also allow received documents to be read without the difficulties traditionally associated with attaching binary files to an email letter. The authoring components of the invention pass data to the main email component which packages the data as a MIME compliant message. When the message is received, the main email component concatenates (as needed) and decodes the MIME message and sends the data to the authoring/reading component associated with the MIME type.
My previously incorporated parent application broadly disclosed and claimed mailbox handling software whereby messages of different types are displayed in different ways in a mailbox listing within the context of the modular component email software.
It is believed that certain features disclosed in my parent application are applicable to any email client software and may be used to improve the process of attaching files to email and using files attached to email.
It is therefore an object of the invention to provide an electronic mail program which includes an inbox list whereby different kinds of messages and attached documents are displayed with different kinds of icons.
In accord with this object which will be discussed in detail below, electronic mail client software according to the invention has a mailbox displayer which lists messages together with an icon for each message where the icon is associated with the MIME type of the message. Mail which contains a file attachment is listed in the inbox with an icon indicative of the type of file attached to the email. The mailbox displayer interprets the MIME type and selects the appropriate icon either from the icon registry in the OS or from a directory of icons maintained by the email client software. For example, if an email with an ADOBE ACROBAT file attachment is received, the ADOBE ACROBAT icon will appear in the mailbox listing alongside the mail item listing. In addition, if a message is created with a special authoring/reading component as described in my parent application, the icon associated with the authoring/reading component will be displayed in the mailbox listing as part of the line displaying the mail item.
The electronic mail software of the present invention is described by example with reference to the email software of my parent application which includes a main email component and a number of installable components which communicate bidirectionally with the email component through an application programming interface (API). The installable components include authoring/reading components as well as a mailbox displayer component. According to the presently preferred embodiment, a component is also included for maintaining a database of icons.
The mailbox displayer component functionality is invoked by the user when the mailbox is opened, when the list of mail is scrolled, etc. The mailbox displayer component preferably includes all of the functionality of state-of-the-art mailbox displayers and includes the functionality of looking to a directory of icons for display with information about the message based on the MIME type of the message. In the Lingo embodiment, a data structure is created for each message with an additional TYPE field that is based on the MIME type and subtype of the message. The internal TYPE field is used to associate MIME types to icons. Another embodiment uses the contents of xe2x80x9ccontent-typexe2x80x9d (MIME type) header of the message directly to associate with icon images. If there is no appropriate icon in the directory of icons, the mailbox displayer uses icon image data contained in a subpart of the MIME message if it is available. Otherwise, no icon or a generic icon is used. According to the presently preferred embodiment, a type table is maintained by a type updater component. The type table includes a list of message types and subtypes together with filenames of scalable icons to be used by the mailbox displayer. The invention prefers scalable icons so that the icon can be sized to accompany the font size chosen to display the mailbox contents.
Several embodiments of the type updater component are provided. According to the first embodiment, icons are installed/removed manually by the user. According to a second embodiment, icons are automatically installed/removed when modular authoring/reading components are installed/removed. According to a third embodiment, new icons are added automatically whenever a new message type is encountered by the mailbox displayer. The new icon is retrieved from either the operating system registry or from the icon image data embedded in the message. According to a fourth embodiment, the type updater automatically queries a network server for new icon information and downloads icon image data as needed.
Additional objects and advantages of the invention will become apparent to those skilled in the art upon reference to the detailed description taken in conjunction with the provided figures.